Certificate Trust Model

Here is another challenge. When you receive a certificate, for example, from email. The certificate indicates the owner's name is Bob. How can you be sure that the certificate really belongs to Bob? Remember Eve can generate a certificate with same name called "Bob" and can snooping on the net to intercept the emails between Bob and you. Refer to FAQ: man-in-the-middle-attack for more information about this kind of attack.

Fortunately each certificate has its unique thumbprint, like a person does. If you can find a way to verify the certificate's thumbprint with Bob then you are sure that the certificate really belongs to Bob not someone else.

Direct Trust

One way to verify the thumbprint is your calling Bob and having him read his certificate's thumbprint to you. Once the thumbprints match you are sure that the certificate is really Bob's and any emails encrypted with this certificate can only be read by Bob with his private key. This is so call direct trust in which the communicating parties are responsible for doing all the hard work of thumbprint verification. This is the most basic form of certificate trust.

If the number of people you correspond with is small you can, for example, call each of them to verify the certificate thumbprints. If, however, you correspond with a lot of people this is not an easy task. That is why we need to use other mechanisms to verify the validity of a certificate.

Note: Direct trust is the only way of trusting a certificate in iSafeguard™ versions before 3.0.

Hierarchical Trust

In the hierarchical trust model everybody's certificate is issued by a third party called Certificate Authority (CA). If one trust the CA then he automatically trust the certificates that CA issues. This is a simplified form of hierarchical trust model. In reality there are a number of root certificate authorities from which trust extends. These CAs may issue certificates themselves, or they may issue certificates that are used to issue certificates down some chain.

The whole structure is like a trust tree. End (leaf) certificate is verified by tracing backward from its issuer to the issuer's issuer until a directly trusted root CA is found. Again we see direct trust here.

The above description is simplified for illustration purpose. But it does make the point: a trusted third party is required to build the trust relationship without direct contacts among communicating parties.

Indirect Trust Model

The trusted party, however, does not have to be a CA. Actually not everyone has a certificate from a CA. Many people use self-signed certificates for communicating with their friends and family members. They can use direct trust or use the so-called indirect trust described below.

When Bob hands you his certificate on a disk you know the certificate is really his. You establish the trust through direct trust. Therefore you mark this certificate as trusted. Bob does the same thing with your certificate. So Bob and you can communicate securely. In the similar way you trust Alice's certificate and mark hers as trusted.

One day Bob wants to communicate with Alice securely. It is impossible for Alice to hand her certificate to Bob personally since they are hundreds of miles away from each other. Bob could ask her to email her certificate to him and then give her a call to verify the thumbprint. This may not be always possible; Bob may not have her phone number, for example.

Or alternatively Bob could ask you to sign Alice's certificate and send the signed certificate to him since you have her certificate and have verified the thumbprint with her. When Bob receives Alice's certificate with your digital signature he can verify the digital signature with your certificate he has already had and trusted. Once the verification is successful Bob can be sure he gets Alice's certificate and can communicate with her securely. This is so called indirect trust. The trust between two communicating parties is established through a trusted third party - you.

This trust model is particularly useful when communicating parties don't use a common certificate authority.

Trust Models Used In iSafeguard™

Starting from version 3.0 iSafeguard™ supports direct trust, indirect trust and hierarchical trust. For self-signed certificates (including root CA certificates) direct trust and indirect trust models are used. For CA-issued certificates hierarchical trust model is used.

The following is a list of the trust rules used in iSafeguard™:

1. Self-signed certificates are trusted directly by verifying their thumbprints with the certificate subjects.
2. Self-signed certificates with private keys are trusted; no matter they are CAs or end entities.
3. Self-signed certificates, including root CA certificates, signed by directly-trusted certificates are trusted.
4. Certificates, with or without private key, issued by a trusted CA certificate is trusted.
5. A CA certificate is trusted only if its issuing CA certificate is trusted.

Note: A certificate is called directly-trusted certificate if

• The certificate is self-signed and you have the corresponding private key; or
• You get the certificate through a secure channel, someone hand you his certificate, for example; or
• You have verified its thumbprint with its subject through a secure channel.

Certificate Validity and Certificate Trust

A certificate is said to be trusted if you are sure the certificate really belongs to the subject shown on the certificate.

A certificate is said to be valid if it is trusted and in its valid time period and not being revoked.

Certificate Revocation

Here is another question you may have regarding certificate. What if my private key is compromised? Or I don't use a certificate anymore? Well if you use certificates issued by a Certificate Authority (CA) you may revoke your certificate by working with the CA. The CA will publish a list of revoked certificate, called Certificate Revocation List, periodically. For example Thawte allows you to revoke your certificate using their web site. Thawte then will add your certificate to the list of revoked certificates.

iSafeguard™ fully supports Certificate Revocation List. When checking the validity of a certificate iSafeguard™ will check against your CA's CRL to make sure it is not revoked before allowing you to use it to sign and encrypt data.